IEFinance Partner Portal – Loan Application Redesign

A broker portal redesign for IEFinance to streamline the loan application workflow, improve data accuracy, and provide early compliance insights using CRO and Revenue data. My role included end-to-end UX/UI design over four months.

My Role

UX/UI Designer — Led end-to-end redesign of the broker loan application, from research and IA to high-fidelity UI and prototyping using IBM Carbon.

Tools

Figma · IBM Carbon · Miro · FigJam · Notion

Timeline

4 months (Research → Design → Prototype → Testing)

Problem

The IEFinance Partner Portal redesign focuses on improving the end-to-end loan application experience for brokers and financial partners. The existing system relied heavily on manual data entry, fragmented information sources, and inconsistent workflows, creating unnecessary friction during the application process.

Insight

Case

  • The portal has not been widely adopted. Partners often reach out directly to IEFinance’s sales support via calls and emails, leaving IEFinance staff to complete the application on their behalf.
What happens typically
Ideal streamline

Discover

How I investigated the problem.

I began by analysing the existing partner portal to understand its workflow, pain points, and data gaps. This revealed unclear progress, fragmented information, and early data demands on brokers. These insights led me to create a Service Blueprint mapping broker actions, IEFinance processes, and external data sources, helping identify where UX improvements, automation, and early compliance indicators would add the most value.

The partner's phase process:
Existing Portal Screen view
Existing portal screen view

Service Blueprint

I began by analysing the existing partner portal to understand its workflow, pain points, and data gaps. This revealed unclear progress, fragmented information, and early data demands on brokers. These insights led me to create a Service Blueprint mapping broker actions, IEFinance processes, and external data sources, helping identify where UX improvements, automation, and early compliance indicators would add the most value.

Survey Simulation

To validate my early assumptions, I conducted a survey simulation based on industry research and broker discussions. While I did not have access to real users, this approach helped test whether the identified pain points aligned with common broker challenges in SME lending.

My key survey questions
Main Challenges
What Brokers Value Most (client-focused factors)
Insight

These early signals were validated through exploratory research, confirming friction around document collection, manual admin workload , and communication speed .

Exploratory Research

I conducted exploratory research across lender documentation, broker-focused articles, and industry reports to validate early signals around delays in loan applications. This research confirmed that document collection is the primary bottleneck, driven by incomplete submissions, unclear requirements, and repeated follow-ups.

Validated insights

  1. Brokers spend significant time chasing missing or incorrect documents
  2. Incomplete submissions cause rework and internal handoffs
  3. Speed and clarity are critical to broker confidence and throughput
Evidence From Industry Research
Why delay?

Field Research: Empathy Map

This empathy map captures the behaviours, thoughts, and emotional states of brokers during the SME loan application process, based on exploratory research and validated survey signals.

Synthesis: What this revealed

  1. Brokers feel responsible for progress but lack control over document flow.
  2. Repeated document requests create frustration and loss of confidence
  3. Delays are emotional (stress, embarrassment), not just operational

Define

Problem Statement

WHO

Financial partners (brokers) submitting SME loan applications through IEFinance’s Partner Portal.

NEED

A faster, clearer way to progress applications using the information and documents they already have — with transparency around what is required, when, and why — without waiting on clients or repeatedly interrupting the process.

INSIGHT

Because the portal requests detailed customer information and documents too early, brokers are unable to progress applications independently. This leads to delays, frustration, and reliance on IEFinance’s Sales Support instead of the digital portal.

BUSINESS IMPACT

Early friction causes brokers to abandon the portal mid-application, increasing manual workload and slowing loan processing.

User Persona

Separated the Persona into Two Types

Personas were created through exploratory research, combining repository research and empathy mapping, and synthesised using a proto-persona approach.

INSIGHT

Both personas share similar pain points within the IEFinance process — complexity, document delays, and lack of clarity.However, their motivations and expectations differ, shaping how each reacts to these challenges.
Caroline seeks reassurance and trust, while Alex seeks efficiency and control — and these differences guide distinct UX strategies for improving the portal experience.

Persona - Jobs to be done

This section captures the core jobs each partner is trying to accomplish across the loan application journey.

Alex Murphy persona Caroline Byrne persona
INSIGHT

Core Shared Job to Be Done (Both Personas)

Complete and submit accurate loan applications with confidence and minimal friction, while clearly understanding what is complete, what is missing, and what happens next — without unnecessary rework or delays.

Alex wants the system to do the heavy lifting, so he can move quickly and confidently across multiple applications. Caroline wants the system to support her judgement and communication, so she can confidently guide clients and maintain trust. Both partners want to submit accurate applications with minimal friction — Alex prioritises speed and control, while Caroline prioritises clarity, trust, and continuity.

Persona × Journey Map

To translate personas into actionable design insights, I analysed how each persona experiences critical phases of the application journey.

Alex Murphy’s Journey Map

The Tech-Savvy Efficient Partner

His goal: to complete the client’s loan application quickly and accurately, without needing back-and-forth communication or manual rework.

Caroline Byrne’s Journey Map

The Experienced Relationship-Driven Partner

Her goal: is to submit a complete and accurate loan application, even when client documents are delayed or flawed — while also ensuring she can clearly advise her clients on what’s missing or incorrect to prevent delays or rejection.

Ideate

Building on the personas and their Jobs to Be Done, I translated key pain points into How Might We statements to explore solution directions. These questions helped me identify where the loan application experience could better support partners throughout the journey.

Alex Murphy
Alex Murphy

— The Tech-Savvy Efficient Partner

INSIGHT

How Might We Statements

Users lack clarity at submission

HMW can we give partners real-time visibility into application progress so they stay in control?

Re-uploading valid documents slows down Alex’s workflow

How might we reuse previously submitted, valid documents?

Errors or completion status are discovered too late

How might we surface errors and confirm completion instantly?

DECISION

Persistent real-time progress tracking.

Intelligent document reuse

Real-time validation & clear completion states

Alex Murphy
Alex Murphy

— The Experienced Relationship-Driven Partner

INSIGHT

How Might We Statements

Missing docs block progress

How might we allow partners to submit partial KYC documents, showing what’s missing?

Repetition breaks continuity

How might we reuse verified client data so partners don’t repeat steps ?

Changes create uncertainty

How might we help partners stay confident and informed when company information changes?

DECISION

Partial submission + missing indicators

Persistent client data reuse

Change indicators + contextual explanations

Develop

Design Process | Structuring the End-to-End Portal Journey

I mapped the full broker journey from entry to submission to validate task order, responsibility boundaries, and system feedback before refining UI or interactions.

Entry

Entry screen 1 Entry screen 2

Data Collection

Data collection screen 1 Data collection screen 2

Recommendation

Recommendation screen

Review & Compliance

Review screen 1 Review screen 2 Review screen 3

Submission

Submission confirmation

The journey illustrates how brokers progress from initial access through data collection, product recommendation, and multi-stage review before submission. At this stage, the focus was on validating task order, responsibility shifts, and system clarity — deliberately removing visual styling to prioritise usability.

UI Concept — Adapting IBM Carbon for a Broker-Focused Workflow

Adapted Carbon Tile — Recommended Finance Product

Built on IBM Carbon’s expandable tile pattern, this component was iterated to refine action hierarchy, icon alignment, and content density within the expanded state. Testing focused on keeping key decisions in context while ensuring the tile remained scannable and predictable for brokers.

  1. A contextual tag is used to indicate the system-recommended finance option, providing clarity without implying approval or validation status.
  2. Action hierarchy within the expandable tile was refined through testing to guide brokers from review to progression without breaking context or increasing cognitive load.
Contained List → Verification Container

At this stage of the flow, the system is verifying externally sourced data and guiding brokers on where attention is required, without implying approval or failure. At the data verification stage, IBM Carbon’s contained list component was adapted to support layered attention without introducing validation or approval semantics. To support this, a single Carbon component (Contained List) is reused with layered signals at different levels.

  1. Informational tags summarise dataset changes, row-level highlights localise mismatches.
  2. The row highlight means: “This specific data value has been flagged by the system and requires broker attention or verification.”
  3. Inline indicators act as persistent reminders —guiding brokers through verification while maintaining trust in externally sourced data.
Alert-Triggered Resolution Panel — Adapted Carbon Accordion

When a data mismatch requires explicit broker action, an alert-triggered resolution panel is introduced. Built on Carbon’s accordion pattern, the component expands only when needed to present change context, structured comparison, and clear resolution actions. Informational tagging and restrained emphasis guide compliance decisions without interrupting the broader application flow.

  1. Header Title — Alert Scope Identifier anchors the alert to a specific data field.
  2. The tag maintains semantic consistency with the earlier verification container.
  3. Icon: indicates if the panel is open or closed.
  4. Presents all information required to resolve the alert: Explicit resolution actions

Workflow Transition - Mid Fidelity

Based on research findings, pain points, and system constraints, I proposed an end-to-end workflow outlining how brokers could move from data entry to submission. This workflow was first articulated in low fidelity to define structure, sequence, and responsibility boundaries, and then translated into mid-fidelity designs to explore component behaviour, feedback patterns, and system responses.

Workflow User Journey

The transition from low to mid fidelity did not involve changing the workflow itself. Instead, it focused on making the proposed flow concrete and testable by introducing clearer information hierarchy, design-system components, and system feedback.

Component & Layout Iteration

Improvements Based on Mid-Fidelity Testing

Mid-fidelity testing focused on how brokers interpret system feedback, resolve detected data changes, and progress through review stages. Testing highlighted issues around clarity, visual hierarchy, and action placement rather than task order.

Refining the Recommended Product Interaction

This iteration focused on improving the discoverability of additional product details while preserving clarity between borrowing details and the system-recommended option.

Before (Initial version)
Recommended product – initial version

The expand control for the recommended product was visually understated, causing users to overlook the availability of additional product details. While the recommendation itself was clear, accessing deeper information required extra scanning.

After (Iterated version)
Recommended product – initial version

The expand affordance was made more discoverable and aligned more closely with the recommended product content. Additional finance information was surfaced in a clearer, more intentional way, supporting partners who needed to explain the recommendation in greater detail to clients.

Evidence

The iteration reduced hesitation around accessing extended details while maintaining a clear visual link between client inputs and the system-recommended product.

  1. Improved visibility of the expand/extend affordance
  2. Preserved side-by-side alignment to maintain data → recommendation connection
  3. Used progressive disclosure to avoid overwhelming users
  4. Supported partner needs for deeper explanation, not just quick selection
Preparing the Interface for High Fidelity

As the design moved toward high fidelity, refinements focused on visual hierarchy, semantic colour usage, and accessibility—without changing component behaviour or workflow.

Before (Initial version)
After (Iterated version)
  • Semantic colour correction: Alert colour usage was refined so that tags, headers, and notifications each map to a single semantic role, improving contrast and reducing visual competition.
  • Header vs notification separation: Accordion headers were returned to a neutral surface, reserving alert colour for notification and resolution content.
  • Value layout clarity: Spacing and alignment of previous vs updated values were refined to support faster comparison and confident decision-making.
Proposed Interaction Pattern: Contextual Drawer for KYC

This interaction was explored as a proposed solution to manage complex KYC tasks without breaking table context.
It was lightly tested with a small number of users to assess discoverability and basic usability. Participants were able to locate the overflow menu and complete document uploads via the drawer, indicating that the interaction was understandable, though not fully validated at scale.

  • Semantic colour correction: Alert colour usage was refined so that tags, headers, and notifications each map to a single semantic role, improving contrast and reducing visual competition.
  • Header vs notification separation: Accordion headers were returned to a neutral surface, reserving alert colour for notification and resolution content.
  • Value layout clarity: Spacing and alignment of previous vs updated values were refined to support faster comparison and confident decision-making.

Prototype

The final prototype demonstrates how brokers can progress through complex loan applications with greater clarity, reduced manual effort, and clear system feedback—while maintaining compliance and auditability.

What I would do differently

Earlier access to broker partners

In this B2B project, limited access meant relying on exploratory research, informed assumptions, and AI-assisted surveys. While directionally validated, direct broker input would have strengthened confidence in user and loyalty flows.

Testing with real users and metrics

Usability testing was conducted with participants close to the target context. With real brokers, I would measure task completion time, error rates, and drop-off to quantify improvements.

Broader UI exploration

Time constraints focused UI work on adapting the IBM Carbon Design System. With more time, I would further refine the UI and explore alternative systems while maintaining Carbon for enterprise consistency.

Next Steps

  1. Integrate AI-assisted data detection to identify missing, inconsistent, or risky inputs earlier in the flow
  2. Document data-detection states (missing, matched, risk) and pack-status variations within the design system
  3. Evolve the compliance workflow by standardising how tax returns and annual accounts are evaluated and surfaced

Certifications & Acknowledgement

Working on this project through the UX Tree mentorship programme was a genuinely rewarding experience, and I’m grateful for the support and encouragement throughout the process.
To my mentor, Alessia Rossini, I’m very glad I had the opportunity to work with you. You dedicated a great amount of time to supporting me on a complex project focused on redesigning a loan application. I truly appreciate your guidance and experience, which helped me stay focused and expand my UX design methodologies—incorporating more up-to-date, technology-aligned approaches.
Thank you as well to the mentors and mentees who shared feedback, tested the designs, and offered thoughtful insights along the way. Your input strengthened the project and gave me valuable perspectives throughout the process.
Thank you!

UX Tree Mentorship Certification
UX Tree Mentorship Programme
UX Tree Case Study Certification
UX Tree Case Study Certification